The “AUID” Type

“AUID” in the Types Register

In the Types Register, the “AUID” Type is a “Record” of four differently sized blocks of data such that an instance of this Type has 16 bytes.

For reasons that will become apparent below, it is best to treat this modelling of the Type (that is, as four differently sized blocks of data) as arbitrary and irrelevant. Think of an instance value of this Type simply as consisting of 16 bytes of data. These 16 bytes can represent either a UL or a UUID.

“AUID” in MXF

SMPTE ST 377-1 very clearly describes the “AUID” and “IDAU” Types (“IDAU” is not in the Types Register currently and no examples of its use are known). An instance value of either Type can be a UL or a UUID. The difference between them is the byte storage order:

• “AUID”: A UL is stored “straight” but a UUID is stored “swapped”
• “IDAU”: A UUID is stored “straight” but a UL is stored “swapped”

This explains why it is OK that there are examples of Elements in MXF standards which have a UL Type but are given the “AUID” Type in the Registers (indeed, there is no UL Type in the Types Register).

The “AUID” Type in the Registers is implemented in an MXF file as what MXF describes as an “AUID”.

Exceptions to the above:

The following Elements have the Type “AUID” in the Elements Register but are supposed to be implemented in MXF using the Type “UUID”:

• LinkedGenerationID
• GenerationID
• ApplicationProductID

These Elements all exist in AAF with the Type “AUID” and so it would not be appropriate to change the Registers.

It seems that the MXF functions in the AAF toolkit / SDK are aware of the MXF definition of “AUID” but are not aware of the above exceptions. This explains why some real MXF files have been seen which have some of the above Elements (such as “GenerationID”) that contain “swapped” UUID values rather than “straight” UUID values – these real MXF files were from a manufacturer whose products are known to use the AAF toolkit / SDK internally.

So, the above MXF exceptions are not actually adhered to in all MXF files. It is not straightforward to codify when the exceptions do, and when they do not, apply. In the absence of any other guidance, assume that all of the exceptions listed apply to all MXF files.

“AUID” in AAF

The Type “AUID” in the Registers is implemented in an AAF file in the same way as what MXF describes as an “IDAU”. Although this does not seem to be formally defined in AAF it is evident by examining the AAF MetaDictionary which specifies “AUID” literals using “straight” UUIDs and “swapped” ULs.

To be clear, this is the “opposite” of what MXF does.

“AUID” in Reg-XML

The situation in Reg-XML is straightforward: if an instance of an Element with Type “AUID” is actually a UUID then it is formatted as a UUID in the XML document; and if it is actually a UL then it is formatted as a UL in the XML document.

“DataValue” and “VariableArray”s

An instance of the “DataValue” Type is encoded “in-line” – it is simply a piece of binary data whose structure is not defined in the Types Register.

Note that “DataStream” in ST 377-1:2011 appears to be an error – it should say “DataValue”.

Although “DataValue” is modelled as a “VariableArray”, in an MXF file there is no eight-byte header. This is exceptional behaviour – a “VariableArray” is ordinarily implemented in MXF as an “array” which has an eight-byte header. However, note that the AAF toolkit / SDK does expect “DataValue” to have an eight-byte header when performing MXF reading / writing – this means that if this Type is used in an MXF file then the file will not be compatible with the AAF toolkit / SDK.

“IndexEntry” and “DeltaEntry”

Items in an “IndexEntryArray” are of Type “IndexEntry”. An instance of the “IndexEntry” Type is actually a “custom” encoding (similar to pack coding) of the Group that contains all the Elements which describe the Index Entry. These Elements are in the Elements Register but they do not seem to be used by any Group in the Groups Register. This is probably because if this Group were entered it would then be impossible to describe the way in which an instance of it is coded as an item in an “IndexEntryArray”.

It is not possible to model “IndexEntry” as a “Record” because for some Index Table Segments each Index Entry has X Elements and for others it has Y Elements (items cannot be optional in a “Record”).

Given it is impossible to properly model this Type, “IndexEntry” is defined as a “Rename” of “DataValue”.

“DeltaEntry” is also a “Rename” of “DataValue” for consistency.

“Boolean”

ST 377-1:2011 says:

The logical value FALSE shall correspond to the binary value 00h of the byte. All other values shall correspond to the logical value TRUE.

and

MXF decoders shall be able to properly interpret all binary values ranging from 00h to FFh.

Therefore, a “Boolean” is not truly an “Enumeration” (although this is how it is modelled in the Types Register). This situation has arisen because of how the 2004 version of ST 377-1 was written.

“ProductReleaseType”

“ProductReleaseType” is an Enumeration of BaseType “UInt8” in AAF (and the Reg-XML AAF baseline in ST 2001-2) but an “Enumeration” of BaseType “UInt16” in MXF. The Type entry for “ProductReleaseType” in the Registers matches AAF – this is in-line with the approach taken elsewhere in the Registers.

Note that some MXF files are known to actually use the AAF definition of “ProductReleaseType”. So, MXF parsers must determine whether either one or two bytes have been used for each instance of this Type and then interpret as either a “UInt8” or a “UInt16” respectively.

“ProductVersionType”

“ProductVersionType” makes use of “ProductReleaseType” – therefore the notes above are relevant.

“VersionType”

Both the “Record” members have Type “Int8” because this is how the Type is defined in AAF. However, in MXF both of the “Record” members have Type “UInt8”.

ST 377-1:2011 explains clearly how this Type is to be used.

This discrepancy will not cause any practical problems as long as neither “Record” members (“VersionMajor” and “VersionMinor”) go over 127.

“Character”, “UTF16String” and “UTF16StringArray”

In the Types Register the “Character” Type has a definition of A single "UTF-16" code unit. “UTF16String” and “UTF16StringArray” use “Character” as their BaseType.

However, it is believed that in AAF (at least in some circumstances / implementations / documents) instances of these Types are limited to UCS-2 (which is a sub-set of UTF-16). That is, only those code points encoded as single two-byte code units are permitted.

“UTF16StringArray”

“UTF16StringArray” is a Type with TypeKind “VariableArray” and BaseType “Character” (which is defined as A single "UTF-16" code unit). This Type can be useful because it provides a means to concatenate multiple variable-length strings into one data item.

Instances of this Type consist of an array / sequence of “code units”. The strings are demarcated by zero-value “code units” – that is, each pair of strings is separated by a single zero-value “code unit”.

In MXF, instances of the “UTF16StringArray” Type are implemented without the eight-byte header that is ordinarily used for a “VariableArray”.

Labels ULs in AAF “Enumeration”s

There are a number of “Enumeration” Types which have Facets that are ULs of Labels. For consistency the practical Types Register requires that these Label ULs match entries in the Labels Register.

AAF defines several “Enumeration” Types that refer to Labels ULs where the Labels ULs have the version bytes set to 0x01 instead of 0x06 (the latter value matching the Labels Register). These Types have been defined in the Types Register using Labels ULs that match with the Labels Register.

The relevant Labels are:

• “TransferCharacteristic_ITU1361”
• “TransferCharacteristic_linear”
• “CodingEquations_SMPTE240M”